Listing of Claims 



1. (Currently Amended) A computer-implemented method for the intermediation of real 
time meetings, comprising: 

receiving an indication by a requester system that a requester (R-A) wants to request a 
realtime meeting M-A with a target T-A; 

sending to a decider system (D) a request to conduct a real time meeting M-A; 

queuing the request for the meeting M-A by the decider system; 

receiving by the decider system (D) an availability status of T-A; 

receiving by the decider system (D) an availability status of R-A, where a possible 
availability statues includes not available; 

receiving an indication by the requester system that a requester (R-B) wants to request a 
realtime meeting M-B with target T-B, the meeting M-B to be disjoint in time with the meeting 
M-A; and such that one of the parties to M-A (R-A or T-A), known as the 'common party' is also 
the same as one of the parties to M-B (R-B or T-B) and thus there are three distinct parties, the 
decider D being associated with the common party; 

sending to the decider system (D) a request to conduct a real time meeting M-B; 

queuing the request for the meeting M-B by the decider system, such that requests for at 
least two distinct meetings, disjoint in time are placed in the queue, so that multiple pending real 
time meetings for the common party are in the queue at the same time; 

receiving by the decider system (D) an availability status of target T-B; 

receiving by the decider system (D) an availability status of the requester R-B, where a 
possible availability statues includes not available; 

initiating, by the decider, one of the two meetings M-A and M-B by connecting the 
common party and the other party to that meeting when the common party and that other party 
are mutually available; and 

dequeuing the request for a meeting upon its compl e tion . 




2. (Cancelled) 

3. (Previously Presented) The method of claim 1 , wherein a system of the target T-A is 
polled to determine the availability of target T-A. 




4. (Currently Amended) The method of claim 1, wherein the system of the target I -A 
| se«ds- pushes the availability status of target T-A to the decider system. 

5. (Previously presented) The method of claim 1, wherein a system of a party is polled to 
determine the party's availability. 

6. (Currently Amended) The method of claim 1, wherein the system of a party sends 
pushes the party's availability status to the decider system. 

7. (Previously Presented) The method of claim 1, wherein mutual availability is 
determined by checking the availability of one of the target/requester pairs T-A/R-A and T-B/R- 
B. 

8. (Previously Presented) The method of claim 1 , wherein a request is sent to a plurality 
of targets and mutual availability is determined when the requester and one of the plurality of 
targets is available. 

9. -27. (Cancelled) 

28. (Withdrawn) A computer-implemented method for the intermediation of real time 
meetings, comprising: 

receiving an indication that a requester party R-A wants to request a real time meeting M- 
A with a target party T-A; 

receiving an indication that the requester party R-B wants to request a real time meeting 
M-B with a target party T-B, the meeting M-B to be disjoint in time with the other meeting M-A; 

receiving information indicating the availability of the requester party R-A and the target 
party T-A to participate in the real time meeting M-A, the information sent by the requester party 
R-A and the target party T-A and indicating a desire of a human being to take part in a meeting; 

receiving information indicating the availability of the requester party R-B and the target 
party T-B to participate in the real time meeting M-B, the information sent by the requester party 
R-B and the target party and indicating a desire of a human being to take part in a meeting; 

queuing the requests for meetings M-A and M-B by the requester system, such that at 
least two distinct meetings, disjoint in time, are placed in the queue, and such that one of the 
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parties to M-A, known as the 'common party' is also the same as one of the parties to M-B and 
thus there are only 3 rather than 4 distinct parties; 

determining that the common party and one of the non-common parties are mutually- 
available to participate in the real time meeting, in response to the received information; 

responsive to the determination that the common party and the non-common party to M- 
A are mutually available to participate in the real time meeting M-A, initiating the real time 
meeting M-A; and 

responsive to the determination that the common party and the non-common party to M- 
B are mutually available to participate in the real time meeting M-B, initiating the real time 
meeting M-B. 

29.-31. (Cancelled) 

32. (Withdrawn) A system for intermediation of real time meetings, comprising: 

a requester system R-A for receiving a request from a requester party to initiate a real 
time meeting M-A with a target party T-A; 

a requester system R-B for receiving a request from a requester party to initiate a real 
time meeting M-B with a target party T-B, the meetings M-A and M-B being disjoint in time, 
and one of the parties, known as the "common party," common to both M-A and M-B; 

a queue, such that requests for at least two distinct meetings M-A and M-B, disjoint in 

time; 

a first server system associated with the common party's system, the first server system 
for determining availability of the common party and sending the availability of the common 
party; 

a second server system associated with the non-common party in M-A's system, the 
second server system for determining availability of the non-common party in M-A and sending 
the availability of the non-common party in M-A; 

a third server system associated with the non-common party in M-B system, the third 
server system for determining availability of the non-common party in M-B and sending the 
availability of the the non-common party in M-B; and 

a deciding agent in communication with the first server system, the second server system, 
and the third server system, the deciding agent for recording the requests for the real time 
meetings M-A and M-B, for receiving an indication whether each of the three parties are 
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available for the respective real time meetings M-A and M-B, for determining whether the 
common party and one or more non-common parties are mutually available for the respective 
real time meetings M-A and M-B, and for initiating one of the real time meetings M-A and M-B 
when the requestor party and the respective target parties T-A and T-B are mutually available. 

33.-41. (Cancelled). 

42. (Withdrawn) The system of claim 32, wherein the deciding agent is further 
adapted to receive an indication that one or more parties are available by monitoring the activity 
of the parties. 

43. (Withdrawn) The system of claim 32, wherein the real time meeting M-A is 
conducted using a telephone. 

44. (Withdrawn) The system of claim 32, wherein the real time meeting M-A is 
conducted using Internet telephony. 

45. (Withdrawn) The system of claim 32, wherein the real time meeting M-A is 
specified as a face-to-face meeting M-A. 

46. (Withdrawn) The system of claim 32, wherein the real time meeting M-A is 
specified as a text chat. 

47. (Withdrawn) The system of claim 32, wherein the real time meeting M-A is an 
online collaboration tool. 

48. (Withdrawn) The system of claim 32, wherein the real time meeting M-A is a 
shared application. 

49. (Withdrawn) The system of claim 32, further comprising the presence on M-A of 
a plurality of non-common parties, and wherein the deciding agent initiates the real time meeting 
when a quorum of all the parties is available. 

50. -52. Canceled 
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53. (Withdrawn) A computer program product stored on a computer readable 
medium for intermediation of real time meetings, the computer program product comprising: 
program code for receiving an indication that a requester party R-A wants to request a 
real time meeting M-A with a target T-A; 

program code for receiving an indication that a requester party R-B wants to request a 
real time meeting M-B with a target T-B, such that one of the parties to M-A, known as the 
'common party' is also the same as one of the parties to M-B and thus there are only three 
distinct parties, the meetings M-A and M-B being disjoint in time; 

program code means for placing in a queue requests for the two distinct meetings M-A 
and M-B, disjoint in time; 

program code for receiving information indicating the availability of the common party 
and the non-common parties to M-A and M-B to participate in the real time meetings M-A and 
M-B, the information sent by the respective parties and indicating a desire of a human being to 
take part in a meeting; 

program code for determining that the common party and one non-common parties T-A 
and T-B are mutually available to participate in the real time meetings M-A and M-B, in 
response to the received information; and 

program code for initiating respective meetings M-A and M-B, responsive to the 
determination that the common party and at least one of the non-common parties are mutually 
available to participate in the respective real time meetings M-A and M-B. 

54. (Previously Presented) The method of claim 1, further comprising displaying the 
availability status of one of the requesters R-A and R-B on the target system, along with an 
indication that one of the requesters R-A and R-B has requested a meeting. 

55. (Previously Presented) The method of claim 54, wherein the availability status is one 
of in, out, and unknown. 

56. (Previously Presented) The method of claim 1, further comprising displaying an 
availability status of the target T-A on the requester system, along with an indication that the 
requestor has requested a meeting with the target. 



57. (Previously Presented) The method of claim 56, wherein the availability status is one 
of in, out, and unknown. 

58. (Withdrawn) A user interface displayed on a target system, comprising: 

a display showing an ID of a requesting user who has requested a meeting with 

the target; and 

a display showing an availability status of a requesting user, the availability status 
sent by the requesting user. 

59. (Withdrawn) The user interface of claim 58, wherein the availability status is one of 
in, out, and unknown. 

60. (Withdrawn) The user interface of claim 58 showing an age of the request for a 
meeting. 

61. (Withdrawn) The user interface of claim 58 showing a priority of the request for a 
meeting. 

62. (Withdrawn) The user interface of claim 58 showing a reason for the requested 
meeting. 

63. (Withdrawn) The user interface of claim 58 showing additional information about the 
requesting user. 

64. (Withdrawn) A user interface displayed on a system of an owning user, comprising: 

a display showing an ID of a requesting user who has requested a meeting with the 
owning user and an availability status of the requesting user, the availability status sent by the 
requesting user; 

the display further showing an ID of a target user with whom the owning user has 
requested a meeting, and the availability status of the target user sent by the target user. 

65. (Withdrawn) The user interface of claim 64, wherein the availability statuses are one 
of in, out, and unknown. 
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66. (Withdrawn) The user interface of claim 64, showing an age of the request for a 
meetings. 

67. (Withdrawn) The user interface of claim 64, showing a priority of the request for a 
meetings. 

68. (Withdrawn) The user interface of claim 64, showing a reason for the requested 
meetings. 

69. (Withdrawn) The user interface of claim 64, showing additional information about 
the requesting user. 

70. (Withdrawn) The user interface of claim 58, wherein the ID of the requesting user 
and the availability status of the requesting user are displayed in a single display box. 

71. (Withdrawn) The user interface of claim 64, wherein the ID of the requesting user 
and the availability status of the requesting user are displayed in a single display box. 

72. (Previously Presented) The method of claim 1, wherein the decider system a part of 
the system of the common party for whom it is responsible, and wherein the decider already 
knows the status of the common party for which it is responsible. 

73. (Previously Presented) The method of claim 1, wherein the decider system chooses 
to activate one of two real time meetings, where the parties for both meetings are available, 
based on at least one of: 

ranking information including manual ranking through a user interface presented to the 
common party; 

priority information provided by either party; 

the order in time in which the requests were made; and 

relationship information about the parties based on party input or past history. 

74. (Previously Presented) The method of claim 1, wherein the decider system chooses 
to activate one of two real time meetings, where the parties for both meetings are available, 
based on ranking information including manual ranking through a user interface presented to the 



common party. 

75. (Previously Presented) The method of claim 1, wherein the decider system chooses 
to activate one of two real time meetings, where the parties for both meetings are available, 
based on priority information provided by either party. 

76. (Previously Presented) The method of claim 1, wherein the decider sy stem chooses 
to activate one of two real time meetings, where the parties for both meetings are available, 
based on the order in time in which the requests were made. 

77. (Previously Presented) The method of claim 1, wherein the decider system chooses 
to activate one of two real time meetings, where the parties for both meetings are available, 
based on relationship information about the parties based on party input or past history. 

78. (Currently Amended) The method of claim 1, wherein a non-common requester R-A 
or R-B is party to another, distinct meeting request. 

79. (Previously Presented) The method of claim 1, wherein a non-common target is party 
to another distinct meeting request. 

80. (Previously Presented) The method of claim 1, wherein each of the three systems has 
requested and has pending requests for two or more real-time meetings in the queue. 

81. (Previously Presented) The method of claim 1, wherein if all parties become 
available at once, only one of the meetings M-A and M-B will occur immediately and the other 
meeting will remain queued. 

82. (Previously Presented) The method of claim 1, wherein the common party is the 
target T-A and T-B. 
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I 83. (Currently Amended) The method of claim 1 , wherein the common party is the 

requestor R-A and R-B and the common party participates in both of the meetings M-A and M- 
B. 

84. (Previously Presented) the method of claim 1, wherein the target is a specific 
individual selected by the requestor. 

85. (Previously Presented) The method of claim 1, wherein the target is a specific 
individual. 

86. (Previously Presented) The method of claim 1, wherein the common party is the 
requestor R-A and R-B. 

87. (Previously Presented) The method of claim 1, wherein the target is any one of a 
group of targets. 

88. (Previously Presented) A method comprising: 

transmitting or receiving a first request for a first real-time meeting between a requestor 
and a first target, the requestor and the first target being individuals; 

determining that the first target is unavailable, using a computing system; 

waiting until the first target changes from being unavailable to being available; 

when the first target is available, determining if the requester is available; 

if the requestor is available, then initiating the first real-time meeting; and 

if the requester is unavailable, then waiting until a time the requestor becomes available. 

89. (Previously Presented) The method of Claim 88, further comprising: 

in response to the requester becoming available, determining if the first target is still 
available; 

if the first target is still available, then initiating the first real-time meeting; and 
if the first target is unavailable, then waiting until the first target becomes available. 
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90. (Currently Amended) The method of claim 88, further comprising: 
transmitting or receiving a second request for a second real-time meeting between the 

first requester and a second target, the second request being transmitted or received between a 
| time the first request is transmitted or received and a time the first real-time meeting is initiated: 
and 

initiating the second real-time meeting prior to the first real-time meeting if the second 
target becomes available before the first target. 

91. (Currently Amended) The method of claim 88, further comprising; 
transmitting or receiving a second request for a second real-time meeting between a 

second requestor and the first target, the second request being transmitted or received between a 
time the first request is transmitted or received and a time the first real-time meeting is initiated; 
and 

initiating the second real-time meeting prior to the first real-time meeting if the second 
requester becomes available before the first requester. 

92. (New) The method of Claim 78, wherein the non-common requester R-A or R-B that 
is party to another distinct meeting request is a target in that meeting request. 

93. (New) The method of Claim 1, wherein the requestor R-A changes states from not 
available to available, while waiting for the realtime meeting M-A. 

94. (New) The method of Claim 1, wherein the requestor R-A participates in another 
distinct realtime meeting while waiting for the realtime meeting M-A. 

95. (New) The method of Claim 1, wherein the requester R-A becomes available when 
the requestor R-A terminates a call. 

96. (New) The method of Claim 1, wherein the requester R-A and target T-A are both 
available when they are both off of the phone. 
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